1. Field of the Invention
The present invention relates to a computer program optimization method, in particular, to a method for reducing exception handling costs.
2. Description of the Related Art
Of the programming languages in common use today, there are some that treat excessive ranges of data entries or process results as “exceptions”, and handle such exceptions (exception handling). The currently popular Java* language is representative of those that support exception handling (*trademark of Sun Microsystems). Exceptions are roughly sorted into two types. One type is the occurrence of a program status that prevents the continued execution, and the other type is the occurrence of a program status wherein the main control flow in an algorithm is unexpectedly shifted. A convenient method that is often employed to generate an exception handling sequence is one that performs a complicated, reliable procedure to recover from an exception of the second type, whereby the program control flow has been shifted.
The exception handling in Java in this respect will now be briefly explained. In Java, one “try” block is correlated with one or more “catch” blocks, which are so-called handlers (exception handlers), and have exception classes that can be processed as attributes. To continue the execution of a program following the occurrence of an exception, the exception which has occurred in a predetermined try block is thrown, and caught and handled by a matching catch block for the pertinent exception class. Typically, the following steps are performed during exception handling. Firstly, when an exception has occurred in a computer system (hereinafter referred to simply as a system) in which Java codes are implemented as components, the system generates an object of an exception class and initializes the object. Since, in Java, it is defined that a stack trace at that time can be referred to by the exception object, a stack trace is generated at the time of initialization. Then, the exception object is defined as operand, and “athrow” byte code, used to throw an exception, is executed, and in this way the system is set in an exception state.
In the exception state, the system searches for a try block that covers the athrow byte code that has thrown the exception. When the system finds such a try block, the system sequentially examines catch blocks on the list that correspond to the try block to determine whether there is a catch block that can process the current exception class. If such a catch block is found, program control is shifted to that catch block to continue the execution of the program. If no such catch block is found, in the same manner, the system continuously searches for an external or other try block until it finds an appropriate one.
The costs for the exception handling while the program is being executed can be roughly sorted into the cost in search operation for an exception handler (search cost) and the cost in generating and initializing the exception object (generation cost). A conventional technique for reducing the search cost involved in a search made for an exception handler is disclosed in Document 1.
Document 1:
“Efficient Java Exception Handling in Just-in-Time Compilation”, S. Lee, B.-S. Yang, S. Kim, S. Park, S.-M. Moon and K. Ebcio¢glu, in Proceedings of the ACM 2000 Conference on Java Grande, pp. 1–8, New York, N.Y., U.S.A., June 2000 ACM, ACM Press
According to the technique disclosed in this document, firstly, at a point where an exception is thrown, program control branches unconditionally to an exception handler that is predicted without throwing the exception. Then, at the top of the exception handler, a check is performed to determine whether the class of an exception object can be processed by the exception handler. When the class of the exception object can be processed by the exception handler, the process is continued. But when the class of the exception object can not be handled, the exception is actually thrown.
Further, a conventional technique for reducing the process cost for the generation and initialization of an exception object is disclosed in reference document 2.
Document 2
“Practicing JUDO Java Under Dynamic Optimizations”, M. Cierniak, C. Y. Lueh and J. M. Stichnoth, in ACM SIGPLAN '00 Conference on Programming Language Design and Implementation [2], pp. 18–31.
According to the technique disclosed in Document 2, an exception that has occurred is analyzed, and when a compiler ascertains that the generation of an exception object and the performance of the initialization process have no side-effects, and that the compiler does not use an exception handler that is found for an exception object, the generation and initialization of the exception object are eliminated.
As a general idea of the exception handling for a certain program, it is assumed that exceptions seldom occur during execution and that, even if exception handling is required, it can be performed within an extremely short time in an execution period of the program. Thus, it is assumed that the program execution speed can be increased by not imposing heavy overhead for exception handling in sections that no exceptions occur.
Typical methods for searching for an exception handler are a stack unwinding method and a structured exception handling method. According to the stack unwinding method, an exception handler that can catch an thrown exception is searched for, and the stack is traced from the last frame to the preceding frames. In a frame that is optimized to increase the exception handling speed based on the above general idea, information that is unnecessary unless an exception occurs is not included, and in some cases data on program counter is only described therein. Information concerning the frame (whether an exception handler is present, whether a lock is to be released, or whether a callee-saved register is to be recovered) is obtained by searching a code information structure database for a code information structure that corresponds to the program counter. Further, in order to proceed with the stack unwinding, it is first necessary to recover a callee-saved register or to determine whether a current exception can be caught by a frame including an exception handler. Therefore, when an exception occurs, the cost for performing a search for an exception handler can be increased.
Furthermore, according to the structured exception handling method, even if an exception does not occur, a frame including an exception handler is always registered in an execution context. Thus, by skipping those frames that do not include exception handlers when a search operation for an exception handler is performed, the cost for performing the search can be reduced.
As is described above, for a programming language such as Java that supports exception handling, it is relatively easy to generate a robust program. However, reducing the overhead required by exception handling is a critical problem, because a run-time library is usually used to process an exception, and thus, it causes a large amount of processing cost.
For exception handling, it is assumed under the above described idea that, while also assuming that exceptions seldom occur, no overhead for exception handling is required for the section where no exception occurs. However, with the situation that presently exists, wherein exception types that change the control flow of a program tend to be employed in order to easily generate a robust program, deterioration of the execution speed cannot be avoided if a system is designed on the assumption that exceptions seldom occur.
Actually, there are many applications that cause so many exceptions that affect the execution speed of a system. And while most of these exceptions are those that change the control flow, in many cases exception objects are not used. Among the costs incurred for exception handling, the costs for the generation of an exception object and for the performance of an initialization process can be reduced by employing the technique in document 2 and, depending on the application, by generating and reusing an exception object. As for the cost for searching for an exception handler, even if the technique in document 1 is employed, a determination process made to ascertain whether the prediction is correct or not becomes a new overhead. Further, in accordance with this technique, compensation is required in case that the prediction is wrong, though the prediction improves the processing speed. Thus, the costs for the generation and initialization of an exception object cannot be reduced, and the technique in document 1 is therefore not an appropriate countermeasure for reducing exception handling costs.
When the structured exception handling method is employed to perform a search for an exception handler, as is described above, the overhead required for the search can be reduced. However, another overhead is also required to register a frame including an exception handler to an execution context, and when an exception handler is available for a method that is frequently called, the execution speed of the system is drastically deteriorated.
In order to reduce the costs involved in searching for an exception handler, at compile time, an optimization process may be performed to expand a method call inline, wherein an exception may occur. However, indiscreet inline expansion increases the amount of code explosively or deteriorates its quality by requesting more compiling resources. Further, in the dynamic compiling used in Java, memory capacity and the time required for compiling are increased considerably and program pause time is increased, and thus, dynamic compiling is not practical. Specifically, even if static optimization is performed for all the exception handler search processes that could occur, in many cases a reduction in the overhead that corresponds to the optimization cost cannot be obtained. Therefore, it is preferable to select and delete only the exception handler searches that actually occur at the time of execution and affect the execution speed of the system (inlining/inline expansion).
It is, therefore, one object of the present invention to improve the execution speed of a computer system by effectively reducing the costs incurred by a search operation for an exception handler during the exception handling process.
It is another object of the present invention to improve the execution speed of a computer system by optimizing a process that actually affects the execution speed of the system based on the execution frequency of search operations by an exception handler.